Компания VMware перед предстоящей конференцией VMworld 2021 анонсировала скорую доступность для загрузки обновления своей главной серверной платформы виртуализации VMware vSphere 7 Update 3.

Нововведения будут сосредоточены в 3 основных областях:

Deliver AI and Developer-Ready Infrastructure

В новой версии vSphere была улучшена служба для развертывания виртуальных машин через стандартные Kubernetes API Virtual Machine (VM) Service, которая появилась в vSphere 7 Update 2a. Теперь администраторы и DevOps смогут использовать команды Kubernetes для развертывания ВМ на хостах, где включена поддержка vGPU.

Это позволит клиентам самостоятельно запускать AI-нагрузки в виртуальных машинах и просто работать с ними всем участникам процесса обслуживания виртуальной инфраструктуры.

Также было улучшено решение VMware vSphere with VMware Tanzu, которое теперь проще настраивать, особенно в части сетевого взаимодействия, на что ранее жаловались пользователи.

Создать тестовую лабораторию Kubernetes администраторам vSphere теперь стало гораздо легче.

Scale without Compromise

В этой категории улучшений больше всего изменилось в плане поддержки высокопроизводительной памяти Persistent Memory. Например, ее часто используют для таких нагрузок, как SAP HANA. Теперь в vSphere 7 Update 3 есть множество новых инструментов для анализа и настройки производительности памяти с точки зрения пропускной способности (bandwidth) и нагрузки. В дополнение к этому, теперь можно настраивать алармы на базе SLA и изменять конфигурацию машин и платформы на базе рекомендаций от механизма аналитики.

Также, поскольку SSD-хранилища продолжают набирать популярность, а транспорт Non-Volatile Memory Express (NVMe) стал стандартом для многих типов систем, в vSphere 7 Update 3 появилась поддержка NVMe over TCP, которая позволяет использовать стандартную инфраструктуру TCP/IP, оптимизированную под Flash и SSD, для трафика хранилищ. Подробнее об этом рассказано здесь.

Simplify Operations

В новой версии vSphere 7 Update 3 появился специальный vCenter Server plug-in for NSX, который позволяет администраторам гораздо быстрее и удобнее настраивать сетевое взаимодействие и безопасность для NSX прямо из vSphere Client, без необходимости использования NSX Manager. В этой категории также появился простой процесс развертывания и настройки NSX-T, а также бесшовная аутентификация пользователей между vSphere и NSX-T.

Также механизм vSphere Distributed Resource Scheduler (DRS) теперь работает умнее в плане обработки операций обслуживания. Большие и более критичные нагрузки теперь перемещаются первыми и как можно скорее, чтобы пользователи не почувствовали никакого влияния процесса миграции во время обслуживания и апгрейда серверов.

Скачать апдейт VMware vSphere 7 Update 3, который выйдет на днях, можно будет по этой ссылке. Более подробно о новых возможностях обновления также рассказано вот в этой статье.

Весной этого года компания VMware выпустила большое обновление серверной платформы виртуализации VMware vSphere 7 Update 2, включающее в себя множество новых возможностей и улучшений. Основные улучшения знает большинство администраторов, так как об этом писали достаточно подробно. Но есть и несколько небольших, но важных изменений, знать про которые было бы очень полезно. Давайте на них посмотрим...

После выхода VMware vSphere 7 Update 2 появилось много интересных статей о разного рода улучшениях, на фоне которых как-то потерялись нововведения, касающиеся работы с большими нагрузками машинного обучения на базе карт NVIDIA, которые были сделаны в обновлении платформы.

А сделано тут было 3 важных вещи:

• Пакет NVIDIA AI Enterprise Suite был сертифицирован для vSphere
• Появилась поддержка последних поколений GPU от NVIDIA на базе архитектуры Ampere  
• Добавились оптимизации в vSphere в плане коммуникации device-to-device на шине PCI, что дает преимущества в производительности для технологии NVIDIA GPUDirect RDMA

Давайте посмотрим на все это несколько подробнее:

1. NVIDIA AI Enterprise Suite сертифицирован для vSphere

Основная новость об этом находится в блоге NVIDIA. Сотрудничество двух компаний привело к тому, что комплект программного обеспечения для AI-аналитики и Data Science теперь сертифицирован для vSphere и оптимизирован для работы на этой платформе.

Оптимизации включают в себя не только средства разработки, но и развертывания и масштабирования, которые теперь удобно делать на виртуальной платформе. Все это привело к тому, что накладные расходы на виртуализацию у задач машинного обучения для карточек NVIDIA практически отсутствуют:

2. Поддержка последнего поколения NVIDIA GPU

Последнее поколение графических карт для ML-задач, Ampere Series A100 GPU от NVIDIA, имеет поддержку Multi-Instance GPU (MIG) и работает на платформе vSphere 7 Update 2.

Графический процессор NVIDIA A100 GPU, предназначенный для задач машинного обучения и самый мощный от NVIDIA на сегодняшний день в этой нише, теперь полностью поддерживается вместе с технологией MIG. Более детально об этом можно почитать вот тут. Также для этих карт поддерживается vMotion и DRS виртуальных машин.

Классический time-sliced vGPU подход подразумевает выполнение задач на всех ядрах GPU (они же streaming multiprocessors, SM), где происходит разделение задач по времени исполнения на базе алгоритмов fair-share, equal share или best effort (подробнее тут). Это не дает полной аппаратной изоляции и работает в рамках выделенной framebuffer memory конкретной виртуальной машины в соответствии с политикой.

При выборе профиля vGPU на хосте с карточкой A100 можно выбрать объем framebuffer memory (то есть памяти GPU) для виртуальной машины (это число в гигабайтах перед буквой c, в данном случае 5 ГБ):

Для режима MIG виртуальной машине выделяются определенные SM-процессоры, заданный объем framebuffer memory на самом GPU и выделяются отдельные пути коммуникации между ними (cross-bars, кэши и т.п.).

В таком режиме виртуальные машины оказываются полностью изолированы на уровне аппаратного обеспечения. Выбор профилей для MIG-режима выглядит так:

Первая цифра сразу после a100 - это число слайсов (slices), которые выделяются данной ВМ. Один слайс содержит 14 процессоров SM, которые будут использоваться только под эту нагрузку. Число доступных слайсов зависит от модели графической карты и числа ядер GPU на ней. По-сути, MIG - это настоящий параллелизм, а обычный режим работы - это все же последовательное выполнение задач из общей очереди.

Например, доступные 8 memory (framebuffers) слотов и 7 compute (slices) слотов с помощью профилей можно разбить в какой угодно комбинации по виртуальным машинам на хосте (необязательно разбивать на равные части):

3. Улучшения GPUDirect RDMA

Есть классы ML-задач, которые выходят за рамки одной графической карты, какой бы мощной она ни была - например, задачи распределенной тренировки (distributed training). В этом случае критически важной становится коммуникация между адаптерами на нескольких хостах по высокопроизводительному каналу RDMA.

Механизм прямой коммуникации через шину PCIe реализуется через Address Translation Service (ATS), который является частью стандарта PCIe и позволяет графической карточке напрямую отдавать данные в сеть, минуя CPU и память хоста, которые далее идут по высокоскоростному каналу GPUDirect RDMA. На стороне приемника все происходит полностью аналогичным образом. Это гораздо более производительно, чем стандартная схема сетевого обмена, об этом можно почитать вот тут.

Режим ATS включен по умолчанию. Для его работы карточки GPU и сетевой адаптер должны быть назначены одной ВМ. GPU должен быть в режиме Passthrough или vGPU (эта поддержка появилась только в vSphere 7 U2). Для сетевой карты должен быть настроен проброс функций SR-IOV к данной ВМ.

Более подробно обо всем этом вы можете прочитать на ресурсах VMware и NVIDIA.

Мы несколько раз писали об онлайн-сервисе VMware vSphere DRS Dump Insight, который позволяет показывать различную информацию по перемещению виртуальных машин в кластере DRS на портале самообслуживания, куда пользователи могут загружать файлы дампов.

Это позволяет вам получить ответы на следующие вопросы:

• Какие рекомендации DRS сделал на основе анализа cost/benefit
• Почему DRS сделал именно эту рекомендацию
• Почему DRS вообще иногда не делает рекомендаци для балансировки кластера
• Как кастомное правило affinity/anti-affinity влияет на балансировку в кластере
• Где взять полный список рекомендаций DRS

На днях у VMware вышло руководство пользователя по этой утилите, которое будет интересно почитать всем администраторам кластеров VMware DRS, решившим начать анализировать дампы DRS:

DRS Dump Insight User Guide небольшой и занимает всего 20 страниц, но там есть очень конкретные рекомендации по работе с интерфейсом утилиты и по трактовке ее результатов:

Напомним, что DRS Dump Insight в целом может делать следующие вещи:

• Автоматизация воспроизведения дампов (с помощью встроенных кастомных DRS replayers)
• Предоставление и визуализация дополнительной информации, которая недоступна в обычных анализаторах логов
• Парсинг и анализ логов для понимания и наглядного отображения решений балансировщика DRS
• Генерация итогового результата в текстовом формате

Скачать VMware vSphere DRS Dump Insight User Guide можно по этой ссылке.

Как вы знаете, при обновлении виртуальной инфраструктуры в части хостов ESXi с помощью vSphere Lifecycle Manager (vLCM), в кластере HA/DRS хост переводится в режим обслуживания (Maintenance mode), который предполагает эвакуацию виртуальных машин на другие серверы с помощью vMotion. После обновления хоста он выводится из режима обслуживания, и виртуальные машины с помощью DRS постепенно возвращаются на него. В зависимости от характера нагрузки этот процесс может занять от нескольких минут до нескольких часов, что не всегда соответствует ожиданиям администраторов.

Второй вариант - потушить виртуальные машины, обновить ESXi, а потом включить его - тоже не подходит, так как приводит к длительным простоям сервисов виртуальных машин (нужно не только время на обновление хоста, но и время на выключение и включение ВМ, либо их небыстрый Suspend на диск).

Поэтому VMware придумала технологию Suspend-to-Memory, которая появилась в VMware vSphere 7 Update 2. Суть ее в том, что при обновлении ESXi его виртуальные машины приостанавливаются, сохраняя свое состояние (Suspend) в оперативной памяти. Очевидно, что в таком состоянии перезагружать хост нельзя, поэтому данная техника используется только совместно с ESXi Quick Boot, которая подразумевает обновление гипервизора без перезагрузки сервера.

Надо отметить, что функции Quick Boot доступны не для всех серверов. Более подробная информация по поддержке этой технологии со стороны серверных систем приведена в KB 52477, а вот ссылки на страницы вендоров серверного оборудования, где можно узнать детали поддержки этой технологии:

• Quick boot on Dell EMC
• Quick Boot on HPE
• Quick Boot on Cisco
• Quick Boot on Fujitsu
• Quick Boot on Lenovo

По умолчанию настройка кластера Cluster Remediation для виртуальных машин выставлена в значение "Do not change power state" для виртуальных машин, что подразумевает их vMotion на другие серверы, поэтому чтобы использовать Suspend to Memory, надо выставить "Suspend to memory", как на картинке выше.

При использовании такого типа обновления vLCM будет пытаться сделать Suspend виртуальных машин в память, а если этого не получится (например, недостаточно памяти), то он просто не будет переходить в режим обслуживания.

Надо сказать, что Suspend-to-Memory поддерживает vSAN и работает с такими продуктами, как vSphere Tanzu и NSX-T.

Ну и вот небольшое демо того, как это работает:

Вчера мы писали о новых возможностях обновленной платформы виртуализации VMware vSphere 7 Update 2, а сегодня расскажем о вышедшем одновременно с ней обновлении решения для создания отказоустойчивых кластеров хранилищ VMware vSAN 7 Update 2.

Нововведения сосредоточены в следующих областях:

Давайте посмотрим, что именно нового в vSAN 7 U2:

Улучшения масштабируемости

• HCI Mesh Compute Clusters

Теперь в дополнение к анонсированной в vSphere 7 Update 1 топологии HCI Mesh для удаленного доступа к хранилищам vSAN появилась технология HCI Mesh Compute Clusters, которая позволяет иметь вычислительный кластер vSphere/vSAN без собственных хранилищ, использующий хранилища удаленных кластеров.

Самое интересное, что эти кластеры не нуждаются в лицензиях vSAN, вы можете использовать обычные лицензии vSphere.

Также такие кластеры vSAN могут использовать политики хранилищ, в рамках которых можно получить такие сервисы, как дедупликацию / компрессию или шифрование Data-at-rest:

Также было увеличено число хостов ESXi, которые могут соединяться с удаленным датастором, до 128.

Небольшое видео о том, как создать HCI Mesh Compute Cluster:

• Улучшение файловых служб

Службы vSAN file services теперь поддерживают растянутые (stretched) кластеры и двухузловые конфигурации, что позволяет использовать их для ROBO-сценариев.

• Улучшения растянутых кластеров

Растянутые кластеры vSAN теперь обрабатывают не только различные сценарии сбоев, но и условия восстановления, которые были определены механизмом DRS до наступления события отказа. DRS будет сохранять ВМ на той же площадке до того, как данные через inter-site link (ISL) будут полностью синхронизированы после восстановления кластера, после чего начнет перемещать виртуальные машины в соответствии со своими правилами. Это повышает надежность и позволяет не загружать ISL-соединение, пока оно полностью не восстановилось.

• Технология vSAN over RDMA

В vSAN 7 Update 2 появилась поддержка технологии RDMA over Converged Ethernet version 2 (RCoEv2). Кластеры автоматически обнаруживают поддержку RDMA, при этом оборудование должно находиться в списке совместимости VMware Hardware Compatibility Guide.

• Улучшения производительности

В vSAN 7 U2 была оптимизирована работа с RAID 5/6 в плане использования CPU. Также была улучшена производительность яруса буффера. Это позволяет снизить CPU cost per I/O.

Кроме того, были сделаны оптимизации для процессоров AMD EPYC (см. тут).

Улучшения для задач AI and Developer Ready

Здесь появилось 2 основных улучшения:

• S3-совместимое объектное хранилище для задач AI/ML и приложений Cloud Native Apps.

На платформе vSAN Data Persistence platform теперь поддерживаются компоненты Cloudian HyperStore и MinIO Object Storage. Пользователи могут потреблять S3-ресурсы для своих AI/ML нагрузок без необходимости долгой настройки интеграций.

• Улучшения Cloud Native Storage в vSphere и vSAN
  

Теперь Cloud Native Storage лучше поддерживает stateful apps на платформе Kubernetes. Также vSAN предоставляет простые средства для миграции с устаревшего vSphere Cloud Provider (vCP) на Container Storage Interface (CSI). Это позволит иметь персистентные тома Kubernetes на платформе vSphere и расширять их по мере необходимости без прерывания обслуживания.

Улучшения безопасности

• Службы vSphere Native Key Provider Services

Это механизм, который позволяет использовать защиту data-at-rest, такую как vSAN Encryption, VM Encryption и vTPM прямо из коробки. Также для двухузловых конфигураций и Edge-топологий можно использовать встроенный KMS-сервис, который работает с поддержкой ESXi Key Persistence.

• Средства для изолированных окружений

VMware предоставляет Skyline Health Diagnostics tool, который позволяет самостоятельно определить состояние своего окружения в условиях изоляции от интернета. Он сканирует критические компоненты на проблемы и выдает рекомендации по их устранению со ссылками на статьи базы знаний VMware KB.

• Улучшения Data In Transit (DIT) Encryption

Здесь появилась валидация FIPS 140-2 криптографического модуля для DIT-шифрования.

Упрощение операций

• Улучшения vLCM

Для vSphere Lifecycle Manager появились следующие улучшения:

• vLCM поддерживает системы Hitachi Vantara UCP-HC и Hitachi Advanced Servers, а также серверы Dell 14G, HPE10G и Lenovo ThinkAgile.
• vLCM теперь поддерживает кластеры, которые используют vSphere with Tanzu с технологией NSX-T networking.
• При создании кластера можно указать образ существующего хоста ESXi.

• Улучшения защиты данных

При сбое и недоступности хранилищ хост ESXi, который понял, что произошла авария, начинает записывать дельта-данные с этого момента не только на хранилище, где хранится активная реплика, но и в дополнительное хранилище, чтобы обеспечить надежность данных, создаваемых во время сбоя. Ранее эта технология применялась для запланированных операций обслуживания.

• Поддержка Proactive HA

vSAN 7 Update 2 теперь поддерживает технологию Proactive HA, которая позволяет проактивно смигрировать данные машин на другой хост ESXi.

• Улучшения мониторинга

Здесь появились новые метрики и хэлсчеки, которые дают больше видимости в инфраструктуре коммутаторов, к которой подключены хосты vSAN. На физическом уровне появились дополнительные метрики, такие как CRC, carrier errors, transmit и receive errors, pauses. Также для новых метрик были добавлены health alarms, которые предупредят администратора о приближении к пороговым значениям.

• Улучшения vSphere Quick Boot

Здесь появилась техника ESXi Suspend-to-Memory, которая позволяет еще проще обновлять хосты ESXi. Она доступна в комбинации с технологией ESXi Quick Boot. Виртуальные машины просто встают на Suspend в памяти ESXi, вместо эвакуации с хоста, а потом ядро гипервизора перезапускается и хост обновляется.

Скачать VMware vSAN 7 Update 2 в составе vSphere 7 Update 2 можно по этой ссылке. Release Notes доступны тут.

Бонус-видео обзора новых фичей от Дункана Эппинга:

Компания VMware выпустила большое обновление серверной платформы виртуализации VMware vSphere 7 Update 2, включающее в себя множество новых возможностей и улучшений. Напомним, что прошлый релиз vSphere 7 Update 1 был выпущен в начале сентября прошлого года, так что времени прошло уже немало.

Нововведения второго пакета обновлений сконцентрированы в трех основных областях:

Давайте посмотрим на новые возможности vSphere 7 Update 2 более детально:

1. Инфраструктура AI и Developer Ready

На основе технологий, анонсированных в 2020 году, компании VMware и NVIDIA сделали совместный анонс платформы AI-Ready Enterprise Platform.

NVIDIA объединилась с VMware для виртуализации рабочих AI-нагрузок в VMware vSphere с помощью NVIDIA AI Enterprise. Это позволяет предприятиям разрабатывать широкий спектр решений для работы с искусственным интеллектом, таких, как расширенная диагностика в здравоохранении, умные предприятия для производства и обнаружение мошенничества в финансовых услугах.

NVIDIA предоставляет пользователям уникальный набор утилит и фреймворков для решения AI-задач на платформе VMware vSphere.

Решение AI Enterprise:

• Поддерживает последние поколения GPU от NVIDIA в целях достижения максимальной производительности (до 20 раз лучше, чем в прошлом поколении).
• Поддерживает NVIDIA GPUDirect RDMA for vGPUs.
• Поддерживает разделение NVIDIA multi-instance GPU (MIG), что позволяет обеспечивать горячую миграцию виртуальных машин c vGPU на борту c помощью vMotion.
• Посредством Distributed Resource Scheduler (DRS) обеспечивает автоматическую балансировку машин AI-инфраструктуры по хост-серверам.

Также появились и новые возможности в плане поддержки инфраструктуры контейнеров vSphere with Tanzu:

• Интегрированная балансировка нагрузки на приложения посредством VMware NSX Advanced Load Balancer Essentials edition с поддержкой HA с использованием автоматизаций Kubernetes-native (подробнее об этом тут).
• Сервисный кластер Tanzu Kubernetes Grid и Supervisor-кластер можно обновить до Kubernetes 1.19.
• Улучшенная поддержка сторонних репозиториев, что повышает гибкость и безопасность.

2. Инфраструктурные улучшения и безопасность данных

В этой категории появились следующие новые возможности:

• Новый vSphere Native Key Provider - механизм, который позволяет использовать защиту data-at-rest, такую как vSAN Encryption, VM Encryption и vTPM прямо из коробки.

• Поддержка Confidential Containers для vSphere Pods, которые используют память AMD SEV-ES и CPU data encryption на платформах AMD EPYC.
• Механизм ESXi Configuration Encryption, который использует оборудование Trusted Platform Module (TPM) для защиты ключей ESXi на хостах.
• Техника ESXi Key Persistence, которая дает возможности для защиты данных data-at-rest на изолированных хостах.
• Обновленный документ vSphere Security Configuration Guide.
• Обновленные рекомендации vSphere Product Audit Guides, а также FIPS validation для сервисов vCenter Server.

3. Упрощение операций

• Техника ESXi Suspend-to-Memory, которая позволяет еще проще обновлять хосты ESXi. Она доступна в комбинации с технологией ESXi Quick Boot. Виртуальные машины просто встают на Suspend в памяти ESXi, вместо эвакуации с хоста, а потом ядро гипервизора перезапускается и хост обновляется.
• Оптимизации процессоров AMD EPYC CPU, что приводит к улучшению производительности.
• Поддержка рабочих нагрузок Persistent Memory (PMEM) со стороны  vSphere HA. Это позволяет техникам DRS initial placement и High Availability полноценно работать в кластере.
• Новый функционал решения vSphere Lifecycle Manager with Desired Image Seeding, который позволяет автоматизировать обновление микрокода к желаемому состоянию:
  • Все фичи vSphere Lifecycle Manager теперь доступны для окружений vSphere with Tanzu.
  • Функция Desired image seeding позволяет реплицировать информацию о желаемой конфигурации с референсного хоста, экономя время администратора на настройку.
• Функция vMotion Auto Scaling, которая позволяет автоматически подстраивать производительность в сетях 25, 40 и 100 Гбит.
• Уменьшенное I/O latency и jitter для проброшенных напрямую (passthrough) сетевых адаптеров.
• Улучшенная поддержка Virtual Trusted Platform Module (vTPM) для гостевых ОС Windows и популярных дистрибутивов Linux.
• Улучшения VMware Tools, включая Guest Store - метод для распространения конфигураций и файлов между виртуальными машинами, а также драйверы Precision Clock drivers для службы Windows Time Service.
• Улучшенные vCenter Server REST API, что расширяет возможности по автоматизации операций vCenter.

Ссылки, которые могут оказаться полезными:

• Youtube-канал с новыми фичами vSphere 7 Update 2
• Технические статьи о некоторых новых возможностях
• Документация по vSphere
• Основной сайт VMware vSphere
• Release notes для ESXi 7 Update 2, а также для vCenter 7 Update 2

Скачать VMware vSphere 7 Update 2 можно по этой ссылке.

У компании VMware есть полезная бесплатная электронная книга PowerCLI Cookbook for VMware vSAN, посвященная управлению инфраструктурой отказоустойчивых хранилищ с помощью сценариев, которая будет полезна всем администраторам хранилищ виртуальных сред vSphere / vSAN.

В книге на 127 страницах подробно рассказывается о командлетах для управления всеми аспектами хранилищ с помощью PowerCLI. В документе 3 основных блока:

• Configuration Recipes - разбор примеров использования сценариев для настройки самого окружения vSAN, а именно:
  • Настройка vSAN в новом или существующем кластере
  • Добавление хостов
  • Настройка сетевого окружения
  • Выделение дисков под хранилища
  • Настройка HA и DRS
  • Настройка дедупликации и компрессии
  • Настройка шифрования
  • Конфигурация vSAN Performance Service
• Operational Recipes - это практические примеры сценариев для ежедневного использования и подробный разбор их параметров, а также описание процедур, которые нужно регулярно выполнять в кластере.
• Reporting Recipes - это набор рецептов для вывода информации о конфигурациях, метриках и состояниях, а также представления данных в удобном виде.

Скачивайте PowerCLI Cookbook for VMware vSAN - штука полезная.

Команда PowerCLI компании VMware на днях выпустила обновление средства vSphere Desired State Configuration (DSC) версии 2.2. Механизм DSC есть в экосистеме Windows, начиная еще с Windows Server 2012 R2. С помощью него можно мониторить и управлять конфигурациями систем посредством специальных конфигурационных файлов на базе PowerShell, которые имплементируются через движок Local Configuration Manager (LCM), который должен быть на каждом хосте.

У VMware этот механизм работает несколько иначе, в качестве LCM используется прокси-хост, поскольку LCM не запустить ни на vCenter Server Appliance, ни на ESXi:

Так работал механизм до текущего момента, когда пользователям приходилось разворачивать отдельную Windows-машину под LCM. Но теперь появился модуль VMware.PSDesiredStateConfiguration, который предоставляет пользователям набор командлетов, чтобы скомпилировать и исполнить конфигурацию DCS без использования DSC Local Configuration Manager. Это позволяет использовать как Windows, так и Linux-машину в качестве прокси.

При этом пользователям по-прежнему предоставляется возможность использовать как vSphereDSC с движком PowerShell LCM, так и модуль VMware.PSDesiredStateConfiguration.

Давайте посмотрим, что нового появилось в DCS версии 2.2:

1. Новые ресурсы PowerCLI модуля

Вот они:

1. DatastoreCluster - создание, изменение, апдейт или удаление Datastore cluster
2. DatastoreClusterAddDatastore - добавление датастора к Datastore cluster
3. DRSRule - создание, изменение, апдейт или удаление правил DRS
4. VMHostVdsNic - изменение, апдейт или удаление "VMKernel nic" на vSphere Distributed switch
5. VMHostStorage - включение или отключение программного iSCSI-адаптера 
6. VMHostIScsiHbaVMKernelNic - используется для bind/unbind адаптеров VMKernel Network Adapters к указанному iSCSI Host Bus Adapter

2. Исправления ошибок

Поправлены ошибки в следующих командлетах:

• VMHostVDSwitchMigration 
• VMHostVssTeaming
• NfsDatastore

3. Операция Install/Update для модуля VMware vSphereDSC

Установка модуля теперь делается так:

Install-Module -Name VMware.vSphereDSC

Обновление вот так:

Update-Module -Name VMware.vSphereDSC

4. Новый модуль VMware.PSDesiredStateConfiguration

Как было сказано выше, теперь вы можете использовать Windows или Linux-машину без LCM для использования механизма DCS. Установить модуль можно следующей командой:

Install-Module -Name VMware.PSDesiredStateConfiguration

Новый командлет New-VmwDscConfiguration создает объект VmwDscConfiguration, который содержит информацию о конфигурации. Эту конфигурацию можно задать в ps1-файле и передать ее данному командлету. Например:

$config = New-VmwDscConfiguration -Path ./Site-A.ps1

Командлет Start-VmwDscConfiguration запускает исполнение конфигурации:

Start-VmwDscConfiguration -Configuration $config

Есть командлет Test-VmwDscConfiguration для проверки соответствия текущей конфигурации описанной:

Test-VmwDscConfiguration -Configuration $config

Можно также использовать параметр -Detailed для вывода полной информации по соответствию:

Test-VmwDscConfiguration -Configuration $config -Detailed

5. Новая динамическая конструкция vSphere Node

С помощью vSphere Node можно указать объект VINode (сервер vCenter или хост ESXi) и применить соответствующую конфигурацию к нужному узлу vSphere. Это дает следующие возможности:

• Персистентные сессии

Раньше для каждого подключения каждый ресурс требовал параметров учетной записи для установки сессии VISession. Теперь же если вы используете Vmware.PSDesiredStateConfiguration то можно создать персистентную VISession, которую можно использовать для всех ресурсов DCS.

• Не нужны файлы MOF

Поскольку LCM теперь не используется, то и для командлета New-VmwDSCconfiguration они не требуются. Конфигурация может храниться в переменной, либо в ps1-файле.

Скачать VMware vSphere DSC 2.2 можно по этой ссылке.

Многие администраторы VMware vSphere знают, что для организации кластеров Windows Server Failover Clusters (WSFC) нужен эксклюзивный доступ к LUN, а значит на уровне виртуальной инфраструктуры подходили только RDM-диски. Ранее эти кластеры назывались MSCS, мы писали об их организации в виртуальной среде вот тут.

Такая ситуация была из-за того, что WSFC использует механизм резервация SCSI-3 Persistent Reservations, который координирует доступ к общему дисковому ресурсы. С другой стороны, VMFS использует собственный механизм блокировки LUN, поэтому команды WSFC перехватываются и отменяются, если используются диски VMDK. Поэтому RDM-устройства и использовались как средство маппинга дисков виртуальных машин к физическому устройству LUN.

Оказывается, ситуация поменялась с выпуском VMware vSphere 7, где появился механизм Clustered VMDK. Он позволяет командам SCSI3-PR выполняться и применяться к виртуальному диску VMDK, поэтому вам не нужен отдельный LUN.

К сожалению, все это работает только на хранилищах Fibre Channel.

Чтобы это начать использовать, на уровне датастора надо установить параметр "Clustered VMDK Supported":

Далее нужно понимать следующие условия и ограничения:

• Параметр кластера Windows Cluster "QuorumArbitrationTimeMax" должен быть выставлен в значение 60.
• LUN за этим датастором должен поддерживать команды ATS SCSI (как правило, это всегда поддерживается).
• LUN должен поддерживать резервации типа Write Exclusive All Resgistrants (WEAR).
• VMDK-диски должны быть типа Eager Zeroed Thick и виртуальные машины должны быть как минимум в режиме совместимости с vSphere.
• Не презентуйте LUN, которые используются как кластерные VMDK, для хостов ESXi версий ниже 7.0.
• Не комбинируйте датасторы для clustered и non-clustered VMDK на одном общем кластерном хранилище.
• Выделяйте один датастор на один кластер WSFC, не шарьте один датастор между несколькими инстансами кластеров WSFC.

Максимумы конфигураций для таких кластеров WSFC следующие:

Надо помнить еще о следующих ограничениях (более подробно тут):

• Конфигурация Cluster in a Box (CIB) не поддерживается. То есть надо настроить правила anti-affinity DRS Rules, чтобы разделить узлы кластера / виртуальные машины по разным хостам ESXi. Если вы попробуете такую ВМ с помощью vMotion переместить, то миграция завершится неудачно.
• Горячее расширение VMDK кластерной ВМ не поддерживается.
• Не поддерживается Storage vMotion и снапшоты.
• VMFS 5 и более ранние версии не поддерживаются.

На сайте проекта VMware Labs обновились четыре полезные утилиты, про которые мы уже не раз писали. Давайте посмотрим, что именно в них появилось нового:

1. VMware OS Optimization Tool билд b2001

Про прошлый апдейт этой утилиты мы писали вот тут. Напомним, что это средство предназначено для подготовки гостевых ОС к развертыванию и проведению тюнинга реестра в целях оптимизации производительности, а также отключения ненужных сервисов и запланированных задач.

Что появилось нового:

• Все записи оптимизаций снова добавили в шаблон main user template, теперь можно их тюнинговать вручную.
• Исправлены два параметра аппаратных оптимизаций и ускорения, которые ранее настраивались в одной опции.
• Во время фазы Optimize оптимизации экспортируются в файл json (%ProgramData%\VMware\OSOT\OptimizedTemplateData.json).
• Во время фазы Analyze, если дефолтный файл json существует (то есть образ уже оптимизирован), то он импортируется и используется при выборе оптимизаций с прошлым выбором параметров. Также если выбор дефолтных состояний обязателен, то перед каждым запуском утилиты нужно удалять этот файл.
• Файл OptimizedTemplateData.json можно использовать в командной строке с параметром -applyoptimization.
• Улучшена работа с параметрами для служб Hyper-V, которые требуются для облачного сервиса Azure.

Скачать VMware OS Optimization Tool можно по этой ссылке.

2. vSphere Software Asset Management Tool версии 1.3

Напомним, что Software Asset Management Tool предназначен для сбора подробной информации об инсталляции VMware vSphere на вашей площадке, касающуюся лицензирования - инвентаря и доступности лицензий.

О прошлой версии этой утилиты мы писали вот тут, а вот что появилось нового в версии 1.3:

• Отображение продуктов семейства Tanzu в генерируемых отчетах
• Несколько исправлений ошибок

Скачать Software Asset Management Tool 1.3 можно по этой ссылке.

3. DRS Dump Insight версии 2.0

Напомним, что о прошлой версии Dump Insight 1.1 мы писали здесь. Это портал самообслуживания, куда пользователи могут загружать файлы дампов DRS. 

Давайте посмотрим, что появилось нового:

• Добавлена поддержка дампов vSphere 7.0 и 7.0 Update 1
• Доступен выбор нескольких отдельных дампов для анализа из общего списка
• Исправления ошибок и доработки бэкенда

Скачать DRS Dump Insight можно здесь.

4. Workspace ONE Discovery версии 1.1

Об этой утилите мы писали вот тут. Она позволяет показывать различную информацию об оконечных устройствах на рабочих станциях (Certificate Management, Application Deployment, Profile Management).

Что появилось нового:

• Обновлена иконка приложения
• Появился мониторинг компонентов VMware Horizon Client, VMware Digital Experience Telemetry и VMware Hub Health services

Скачать Workspace ONE Discovery 1.1 можно по этой ссылке.

Какое-то время назад мы писали о первой версии платформы виртуализации VMware ESXi для архитектуры процессоров ARM, которая получила название ESXi-Arm или ESXi Arm Edition. Также мы рассказывали об установке этой платформы на компьютер Raspberry Pi на базе процессора ARM.

Недавно на сайте проекта VMware Labs появилось обновление этой платформы до версии 1.1. Эту версию нужно обязательно ставить заново, потому что обновление с версии 1.0 не поддерживется.

Давайте посмотрим, что там появилось нового:

• Исправлена критическая ошибка, вызывавшая розовый экран смерти (PSOD) при добавлении к коммутатору VDS (см. тут)
• Поддержка аппаратной платформы Arm N1 SDP
• Поддержка виртуальных машин на процессорах Neoverse N1 CPU
• Улучшения стабильности работы на платформах LS1046A и LX2160A
• Исправления ошибок для отображения некорректного использования CPU на vCenter/DRS
• Исправление ошибки с аварийным завершением виртуальной машины при полной заполненности хранилища
• Исправление ошибки с поддержка устройств non-coherent DMA
• Теперь можно ставить гипервизор имея в распоряжении 4% от 4 ГБ памяти вместо 3.125 (критично для некоторых аппаратных платформ)
• Улучшения работы с последовательным портом
• Обновление документации (больше информации об iSCSI, документы по платформам LS1046ARDB и Arm N1SDP, обновлен список поддерживаемых гостевых ОС)

Скачать VMware ESXi Arm Edition 1.1 можно по этой ссылке. Ну и бонусом несколько видео от Вильяма Лама по использованию этой платформы:

Недавно компания VMware объявила о доступности для загрузки новой версии фреймворка для управления виртуальной инфраструктурой с помощью сценариев PowerCLI 12.1. Напомним, что о прошлой мажорной версии PowerCLI 12, вышедшей в апреле этого года, мы писали вот тут.

Давайте посмотрим, что нового появилось в PowerCLI 12.1:

• Несколько новых командлетов было добавлено в модуль VMware.VimAutomation.WorkloadManagement
  • Get-WMCluster
  • Set-WMCluster
  • Enable-WMCluster
  • Disable-WMCluster
• Несколько новых командлетов для vSphere Lifecycle Manager (vLCM) было добавлено в модуль VMware.VimAutomation.Core (подробнее тут)
  • Get-LcmImage
  • Test-LcmClusterCompliance
  • Test-LcmClusterHealth

Вот пример работы Get-LcmImage:

• В модуле VMware.VimAutomation.Core было сделано несколько улучшений, включая новые параметры для командлетов New-Cluster и Set-Cluster, а также New-ContentLibraryItem и Set-ContentLibraryItem. Также были несколько обновлены параметры командлетов New-VM/Set-VM, New-Datastore, New-HardDisk и Get-NetworkAdapter/Get-VirtualNetwork
• Несколько новых командлетов было добавлено в модуль VMware.VimAutomation.Vmc:
  • Get-VmcClusterEdrsPolicy
  • Set-VmcClusterEdrsPolicy

• Обновлен модуль VMware.VimAutomation.Vmc:
  • Улучшен командлет New-VmcSddc (добавлены параметры SddcAppliancesSize, StretchedCluster, HostType)
  • Добавлен параметр Cluster в командлеты Add-VmcSddcHost и Remove-VmcSddcHost
  • Свойства VCenterHostName и VCenterCredentials  добавлены объекту SDDC
• В модуле VMware.VimAutomation.Storage появилось несколько новых командлетов для управления безопасной очисткой дисков vSAN, томами Cloud Native Storage и контейнерами VVols:
  • Start-VsanWipeVsanDisk
  • Get-VsanWipeDiskState
  • Stop-VsanWipeVsanDisk
  • Get/New/Set/Remove-CnsVolume
  • New-CnsContainerCluster
  • New-CnsKubernetesEntityReference
  • New-CnsKubernetesEntityMetadata
  • New-CnsVolumeMetadata
  • Add-CnsAttachment
  • Remove-CnsAttachment
  • Get-VvolStorageContainer
• Улучшения модуля VMware.VimAutomation.Storage:
• Командлеты Set-VsanClusterConfiguration и Get-VsanClusterConfiguration теперь поддерживают режимы "vSAN compression only mode" и "vSAN enforce capacity reservation"
• Get-VsanSpaceUsage более гранулярно показывает статистику свободного пространства
• Командлеты Get-VasaStorageArray и Get-VasaProvider теперь могут фильтровать VASA providers по контейнерам VVols
• Моуль VMware.VimAutomation.Security был существенно обновлен:
• Добавлен командлет Get-TrustedClusterAppliedStatus для получения примененного статуса доверенных сервисов в доверенных кластерах
• Добавлен командлет Set-TrustedCluster для ремедиации кластера в состоянии "not healthy"
• Улучшены командлеты New-TrustAuthorityKeyProvider, Set-TrustAuthorityKeyProvider, Add-TrustedClusterAttestationServiceInfo, Add-TrustedClusterKeyProviderServiceInfo, Remove-TrustedClusterKeyProviderServiceInfo, Remove-TrustedClusterAttestationServiceInfo
  
• Добавлен командлет Disconnect-Vcs в модуль VMware.CloudServices для отключения от сервера VMware Cloud Services
• Модуль VMware.Vim теперь содержит API-байндинги для vSphere 7.0 Update 1
• Модуль VMware.VimAutomation.Srm обновлен в целях поддержки VMware Site Recovery Manager 8.3.1
• Модуль VMware.VimAutomation.HorizonView обновлен в целях поддержки VMware Horizon 7.13
• Модуль VMware.VimAutomation.Hcx обновлен в целях возможности настройки VMware Cloud Director как таргета для миграции HCX OS Assisted
• Командлет Wait-HCXJob теперь лучше получает статус Update-HCXSentinel

Скачать VMware PowerCLI 12.1 можно по этой ссылке, там же доступна и документация.

Какое-то время назад мы писали о новых возможностях недавно вышедшего обновления платформы виртуализации VMware vSphere 7 Update 1. Одним из главных улучшений стало увеличение максимальных параметров платформы, что привело к возможности организовывать кластер HA/DRS из еще большего числа хостов, а на самих хостах - исполнять виртуальные машины еще большего размера.

Данные нововведения можно проиллюстрировать следующей таблицей:

В кластере теперь может быть до 96 хостов, правда не все технологии поддерживают это число. Например, кластер VMware vSAN 7 Update 1 и топология HCI Mesh поддерживают все еще 64 хоста, а технология Native File Services в vSAN 7 U1 поддерживает только 32 хоста.

Самое большое улучшение - теперь в кластере может быть до 10 тысяч виртуальных машин, а это на 50% выше показателя vSphere седьмой версии:

Для виртуальных машин, находящихся под экстремальной нагрузкой, теперь поддерживается 768 виртуальных процессоров (vCPU) и до 24 ТБ памяти. Это больше, чем для виртуальных машин на любой из других облачных или онпремизных платформ:

К подобным нагрузкам можно отнести системы на базе SAP HANA и EPIC Cache Operational Database. Все эти ресурсы виртуальная машина может реально использовать:

Для виртуальной инфраструктуры в целом на базе одного кластера в Sphere 7 Update 1 максимальные показатели следующие: 393 216 vCPU (96 хостов по 4 096 vCPU) / 2.3 ПБ памяти (96 хостов по 24 ТБ):

Если говорить об исполнении контейнеров vSphere with Tanzu в такой инфраструктуре, то их может поместиться просто огромное количество. Согласно статистике, средний размер контейнера составляет 1 vCPU и 400 МБ памяти (например, контейнер node.js "кушает" 1/3 CPU и 384 МБ памяти). Таких контейнеров в одном кластере vSphere 7 U1 может быть запущено 393 216 штук. А контейнеров node.js можно запустить до миллиона экземпляров!

Недавно мы писали о новых возможностях платформы виртуализации VMware vSphere 7 Update 1, а также обновленных функциях платформы для организации кластеров хранилищ VMware vSAN 7 Update 1.

Одной из новых возможностей VMware vSphere 7 U1 стала служба vSphere Clustering Service (vCLS), которая позволяет организовать мониторинг доступности хостов кластера vSphere, без необходимости зависеть от служб vCenter.

Как вы знаете, кластер HA/DRS очень зависит от постоянной доступности сервисов vCenter, который является критическим звеном виртуальной инфраструктуры. Поэтому для него организовывают такие сервисы, как vCenter Server High Availability (VCHA), но и они не идеальны. Также проблема наблюдается при масштабировании кластеров в больших окружениях, которые объединяют онпремизные и облачные площадки, где масштабируемость vCenter является серьезной проблемой.

Учитывая это, VMware придумала такую штуку - сажать на хосты кластера 3 служебных агентских виртуальных машины, составляющих vCLS Control Plane, которые отвечают за доступность кластера в целом:

Таких виртуальных машин три в кластере, где 3 или более хостов, и две, если в кластере два хоста ESXi. Три машины нужны, чтобы обеспечивать кворум (2 против 1) в случае принятия решения о разделении кластера.

Три этих виртуальных машин следят друг за другом и оповещают об этом кластерные службы vCenter:

Это самокорректирующийся механизм, что значит, что если одна из агентских машин становится недоступной или выключенной, то службы vCLS пытаются самостоятельно наладить работу ВМ или включить ее.

Есть 3 состояния служб vCLS:

• Healthy – как минимум 1 агентская ВМ работает в кластере, чтобы обеспечить доступность кластера развертываются 3 ВМ для кворума.
• Degraded – как минимум одна агентская машина недоступна, но DRS продолжает функционировать и исполнять свою логику. Такое может, например, произойти при передеплое служебных машин vCLS или после какого-то события, повлиявшего на их "включенность".
• Unhealthy – логика DRS не выполняется (балансировка или размещение ВМ), так как vCLS control-plane недоступна (то есть ни одной агентской ВМ не работает).

Легковесные машины-агенты исполняются на хостах ESXi и лежат на общих хранилищах, если общие хранилища недоступны - то на локальных дисках. Если вы развернули общие хранилища после того, как собрали кластер DRS/HA (например, развернули vSAN), то рекомендуется перенести агентские ВМ с локальных хранилищ на общие.

Сама гостевая ОС агентских ВМ очень легковесная, используется Photon OS следующей конфигурации:

Диск в 2 ГБ - это тонкий диск, растущий по мере наполнения данными (thin provisioned). Эти машины не имеют своего нетворка, а также не видны в представлении Hosts and Clusters в клиенте vSphere.

Агентские ВМ можно увидеть в представлении VMs and Templates где есть папка vCLS:

Обратите внимание, написано, что для агентских ВМ управление питанием производится со стороны служб vCLS. Если вы попытаетесь выключить эти ВМ, то будет показано следующее предупреждение:

При переводе кластера в режим обслуживания vCLS сам заботится о миграции агентских ВМ с обслуживаемых серверов и возвращении их обратно. Для пользователя это происходит прозрачно. И, конечно же, лучше не выключать эти ВМ вручную и не переименовывать папки с ними.

Жизненный цикл агентских ВМ обслуживается со стороны vSphere ESX Agent Manager (EAM).

EAM отвечает за развертывание и включение агентских ВМ, а также их пересоздание, если с ними что-то произошло. В анимации ниже показано, как EAM восстанавливает ВМ, если пользователь выключил и/или удалил ее:

Важный момент для разработчиков сценариев PowerCLI - это необходимость обрабатывать такие ВМ, чтобы случайно не удалить их. Например, ваш скрипт ищет неиспользуемые и забытые ВМ, а также изолированные - он может по ошибке принять машины vCLS за таковые и удалить, поэтому их надо исключать в самом сценарии.

В интерфейсе vSphere Client список агентских ВМ можно вывести в разделе "Administration > vCenter Server Extensions > vSphere ESX Agent Manager".

У агентских ВМ есть свойства, по которым разработчик может понять, что это они. В частности:

• ManagedByInfo
  • extensionKey == "com.vmware.vim.eam"
  • type == "cluster-agent"

• ExtraConfig keys
  • "eam.agent.ovfPackageUrl"
  • "eam.agent.agencyMoId"
  • "eam.agent.agentMoId"

Основное свойство, по которому можно идентифицировать агентскую ВМ, это HDCS.agent, установленное в значение "true". В Managed Object Browser (MOB) выглядит это так:

Ну и напоследок - небольшое демо технологии vSphere Clustering Service:

Компания VMware анонсировала скорый релиз новой версии платформы для виртуализации и доставки настольных ПК и приложений VMware Horizon 8. Это будет очень большое обновление, включающее в себя новые возможности в самых разных аспектах. Напомним, что о прошлой версии этого продукта Horizon 7.12 мы писали вот тут.

Давайте посмотрим, что там появится нового:

1. Улучшения гибридной инфраструктуры.

Помимо поддержки публичных облачных инфраструктур, уже имеющейся на платформе, будет также добавлена поддержка облаков Google Cloud и VMware Cloud on Dell EMC. Поддержка облака Azure VMware Cloud из статуса Tech Preview перейдет с состояние полноценной производственной поддержки.

Все это позволит пользователям расширить выбор доступных облачных партнеров и строить гибридную виртуальную среду рабочих сред на базе облаков самых разных провайдеров. Управлять всем можно будет через единый интерфейс Horizon Control Plane, а с помощью компонента Universal Broker - назначать унифицированные права доступа в рамках нескольких доступных облаков. Управлять образами и подключенными площадками на базе разных облаков также можно будет из одного места.

2. Улучшения гибкости размещения и доставки виртуальных рабочих столов.

Новая возможность Instant Clones Smart Provisioning расширяет функции мгновенных клонов Instant Clones при их развертывании, а средства Elastic DRS (Distributed Resource Scheduler) дают администраторам возможности динамического расширения пулов виртуальных ПК.

Также теперь решение App Volumes поддерживается для использования в облачной инфраструктуре Horizon Cloud on Azure. Ну а все возможности по интеграции с другими продуктами можно полноценно реализовать через RESTful API. Это все позволяет партнерским решениям просто взаимодействовать с инфраструктурой виртуальных ПК, поддерживая полный цикл работы с ними в рамках предприятия.

3. Улучшения User Experience.

Протокол Blast Extreme был существенно доработан и теперь предоставляет еще больше возможностей по доставке качественного видеопотока, а также при работе с 3D-графикой с использованием кодеков HEVC H.265 и модулей GPU. Поддерживаются также 4K и 8K мониторы.

Пакеты оптимизаций будут доступны для продуктов Zoom и Webex, а также для платформы Microsoft Teams.

4. Безопасность End-to-End Security на базе собственных и партнерских решений.

Как известно, поскольку виртуальные десктопы централизованно хранятся в датацентре компании, их проще защищать централизованно. Интеграция с продуктами Workspace ONE Access, VMware SD-WAN (от VeloCloud), NSX Advanced Load Balancer (решения Avi Networks) и Unified Access Gateway позволяет интегрировать защиту устройств и пользователей в инфраструктуру Horizon.

Кроме того, теперь будет поддерживаться и решение VMware Carbon Black для более специализированного мониторинга инфраструктуры при защите от атак.

Релиз платформы VMware Horizon 8 ожидается до конца октября этого года. Страничка обновления пока доступна тут.

Не так давно мы писали о том, как работает обновленный механизм балансировки нагрузки VMware DRS на новой версии платформы VMware vSphere 7. Напомним, что механизм DRS был полностью переписан, так как его основы закладывались достаточно давно.

Раньше DRS был сфокусирован на выравнивании нагрузки на уровне всего кластера хостов ESXi в целом (на базе расчета стандартного отклонения по производительности), то есть бралась в расчет загрузка аппаратных ресурсов каждого из серверов ESXi, на основании которой рассчитывались рекомендации по миграциям vMotion виртуальных машин. Теперь же механизм запускается каждую минуту, а для генерации рекомендаций используется механизм VM DRS Score (он же VM Hapiness), отражающий удовлетворение потребности виртуальной машины в свободных ресурсах.

В документе "Load Balancing Performance of DRS in vSphere 7.0" компания VMware наглядно демонстрирует ситуации в которых новый DRS отрабатывает лучше старого. Давайте на них посмотрим.

Пример 1 - хост с отклонением нагрузки от большинства

В старом DRS, работающем по принципу выравнивания нагрузки в кластере на базе анализа стандартного отклонения загруженности хостов в рамках определенного порога, могла возникнуть вот такая ситуация, когда DRS не требовалось предпринимать никаких действий по выравниванию нагрузки, хотя они, очевидно, требовались:

Новый DRS работает на базе анализа ресурсов для каждой виртуальной машины и будет перемещать их средствами vMotion, пока не достигнет максимальной доступности ресурсов для каждой ВМ. В точно таком же случае, как описано выше, это приведет в итоге к более сбалансированной ситуации:

Пример 2 - неравномерная загрузка хостов в кластере

В старом DRS был порог по дисбалансу в кластере, и если он не превышен - то механизм балансировки не запускался. Это могло приводить к образованием групп хостов с разными уровнями средней загрузки процессора и памяти:

В ситуации с новым DRS ситуация в итоге, опять-таки, получается более справедливая:

Также полезной оказывается метрика DRS Score (она же VM Hapiness), которая формируется из 10-15 главных метрик машин. Основные метрики из этого числа - Host CPU Cache Cost, VM CPU Ready Time, VM Memory Swapped и Workload Burstiness.

Если все машины чувствуют себя "комфортно" на всех хостах, то DRS Score оказывается максимальным:

Если подать нагрузку на пару хостов ESXi, то их средний DRS Score падает, а на дэшборде указывается число машин, для которых рассчитаны низкие уровни DRS Score:

После того, как DRS обработает эту ситуацию, нагрузка на хосты выравнивается, а значение DRS Score увеличивается:

В документе еще много чего интересного - читайте.

Как вы знаете, компания VMware выпустила платформу VMware vSphere 7 в начале апреля этого года после громкого анонса месяцем ранее. В конце апреля VMware опубликовала интересную новость с результатами исследования среди пользователей, которые тестировали бета-версию vSphere 7 и потом прошли опрос, где одним из вопросов был "Почему бы вы хотели обновиться?". Собственно, вот его результаты...

Компания VMware выпустила на днях обновление одного из самых главных своих документов - "Performance Best Practices for VMware vSphere 7.0". Мы не зря в заголовке назвали это книгой, так как данный документ представляет собой всеобъемлющее руководство, где рассматриваются все аспекты поддержания и повышения производительности новой версии платформы VMware vSphere 7.0 и виртуальных машин в контексте ее основных возможностей.

На 96 листах очень подробно описаны лучшие практики для администраторов платформы и гостевых ОС:

Вот все корневые разделы этого руководства:

• Persistent memory (PMem), including using PMem with NUMA and vNUMA
• Getting the best performance from NVMe and NVME-oF storage
• AMD EPYC processor NUMA settings
• Distributed Resource Scheduler (DRS) 2.0
• Automatic space reclamation (UNMAP)
• Host-Wide performance tuning (aka, “dense mode”)
• Power management settings
• Hardware-assisted virtualization
• Storage hardware considerations
• Network hardware considerations
• Memory page sharing
• Getting the best performance from iSCSI and NFS storage
• vSphere virtual machine encryption recommendations
• Running storage latency-sensitive workloads
• Running network latency-sensitive workloads
• Network I/O Control (NetIOC)
• DirectPath I/O
• Microsoft Virtualization-Based Security (VBS)
• Selecting virtual network adapters
• vCenter database considerations
• The vSphere HTML5 Client
• VMware vSphere Lifecycle Manager
• VMware vSAN performance

Для администраторов больших инфраструктур, активно внедряющих новые технологии (например, хранилища с Persistent Memory или DRS 2.0), появилось много всего нового и интересного, поэтому с книжкой нужно хотя бы ознакомиться по диагонали, останавливаясь на новых функциях ESXi 7 и vCenter 7.

Скачать PDF-версию "Performance Best Practices for VMware vSphere 7.0" можно по этой ссылке.

Frank Denneman обратил внимание на одну интересную новую функцию VMware vSphere 7 - возможность миграции vMotion для виртуальных машин с привязанными ISO-образами.

Как знают администраторы vSphere, часто приходится привязывать ISO-образ к консоли виртуальной машины, чтобы установить какое-то ПО. Нередко этот ISO находится на локальном хранилище машины администратора:

В таком случае, при попытке миграции vMotion данной виртуальной машины выдается ошибка о невозможности выполнения операции в связи с привязанным и активным локальным ISO к виртуальному устройству CD/DVD:

Усугубляется это еще и тем, что такие машины исключаются из миграций DRS, а также не могут быть смигрированы автоматически при переводе хоста ESXi в режим обслуживания (Maintenance mode). Как это обычно бывает, администратор узнает об этом в самом конце, минут через 10 после начала операции по переводу на обслуживание - и агрится от такой ситуации.

Поэтому в VMware vSphere 7 такое поведение пофиксили: теперь при миграции vMotion виртуальное устройство с локальным файлом отсоединяется от исходной машины по команде процесса VMX, все операции с ним буферизуются, далее происходит миграция машины на другой хост, подцепление к нему виртуального устройства с вашим ISO и накатывание буфера.

После переключения машины на другой хост ESXi, VMRC-консоль показывает подключение вашего локального ISO уже к целевой машине:

Казалось бы, мелочь, но иногда может сэкономить немного времени администратора. Для работы этой фичи нужно, чтобы оба хоста VMware ESXi были седьмой версии или выше.

Недавно мы писали о новых возможностях платформы виртуализации VMware vSphere 7, а также функциональности нового механизма динамического распределения нагрузки VMware DRS 2.0. Среди новых возможностей DRS мы упоминали про функции Assignable Hardware, которые позволяют назначить профили устройств PCIe с поддержкой Dynamic DirectPath I/O или NVIDIA vGPU для первоначального размещения виртуальных машин в кластере.

Сегодня мы поговорим об этой технологии в целом. Ранее виртуальные машины, использовавшие технологии DirectPath I/O или vGPU, привязывались к физическому адресу устройства, который включал в себя адрес расположения устройства на конкретной шине PCIe конкретного хоста ESXi. Это делало невозможным использование такой ВМ на других серверах кластера, что, конечно же, делало невозможным и работу технологий HA и DRS, которые являются критически важными в современных датацентрах.

Таким образом, технология Assignable Hardware позволяет отделить виртуальную машину от конкретного устройства и дать ей возможность быть запущенной на другом хосте ESXi с таким же устройством (или даже другим, но поддерживающим определенный набор функций).

Теперь при настройке виртуальной машины у вас есть выбор одного из следующих вариантов для устройства PCIe:

• DirectPath I/O (legacy-режим, без интеграции с HA и DRS)
• Dynamic DirectPath I/O
• NVIDIA vGPU

После того, как вы выберете нужный профиль оборудования, механизм DRS сможет разместить машину на хосте ESXi с поддержкой нужных функций для ВМ.

На скриншоте выше, во второй опции Select Hardware, также есть лейбл "GPGPU example" - это возможность задать определенным устройствам метки таким образом, чтобы при выборе размещения ВМ использовались только устройства хостов с данными метками (при этом модели устройств могут отличаться, например, NVIDIA T4 GPU и RTX6000 GPU). Либо можно выбрать вариант использования только идентичных устройств.

Назначить метку можно во время конфигурации PCIe-устройств. В гифке ниже показано, как это делается:

При использовании NVIDIA vGPU для виртуальной машины выделяется только часть устройства. Поддержка горячей миграции vMotion для машин, использующих vGPU, уже была анонсирована в VMware vSphere 6.7 Update 1. Теперь эта поддержка была расширена, в том числе для DRS, который теперь учитывает профили vGPU.

Ну и в видео ниже вы можете увидеть обзор технологии Assignable Hardware:

Как все уже знают, в скором времени компания VMware сделает доступной для загрузки обновленную платформу виртуализации VMware vSphere 7. О новых возможностях этого решения мы уже писали, а также рассказывали об отдельных улучшениях подробнее (например, о новом DRS).

Сегодня мы поговорим о службах Identity Federation, появившихся в VMware vSphere 7.

В современном мире в корпоративной инфраструктуре все чаще отходят от устаревшей аутентификации по паролям и переходят к практикам двухфакторной (2FA) или многофакторной (MFA) аутентификации. Процесс идентификации пользователей всегда основан на 3 ключевых вещах: что-то вы знаете (пароль), что-то у вас есть (телефон) или кем-то вы являетесь (отпечаток пальца).

Службы Identity Federation позволяют объединить инфраструктуру vCenter Server с другими Identity Providers, такими как Active Directory Federation Services (ADFS), в целях унификации процесса двух- или многофакторной авторизации. Иными словами, пользователи, логинящиеся через 2FA в свой десктоп или в облачный сервис, будут использовать ту же самую процедуру и для операций с vCenter Server.

Будучи подключенным к одному из провайдеров аутентификации (например, ADFS), клиент vSphere Client при логине будет перенаправлять на форму логина данного провайдера. После авторизации на стороне провайдера будет произведено обратное перенаправление с использованием защищенного токена, через который пользователь уже будет работать со службами vCenter.

С точки зрения пользовательского опыта это напоминает, например, логин на веб-сайт с помощью Google или Facebook. Для обмена информацией используются протоколы OAUTH2 и OIDC.

Если вы включите Identity Federation, вы сможете пользоваться традиционными службами Active Directory, Integrated Windows Authentication и LDAP/LDAPS для аутентификации в vCenter Server. Однако надо понимать, что все эти методы аутентификации не затрагивают vSphere Single Sign-on (SSO), который, по-прежнему, используется для внесения административных настроек в саму платформу vSphere.

Более подробно об этом механизме рассказывает Bob Plankers в видео ниже:

Некоторое время назад мы писали о новых возможностях платформы виртуализации VMware vSphere 7, среди которых мы вкратце рассказывали о нововведениях механизма динамического распределения нагрузки на хосты VMware DRS. Давайте взглянем сегодня на эти новшества несколько подробнее.

Механизм DRS был полностью переписан, так как его основы закладывались достаточно давно. Раньше DRS был сфокусирован на выравнивании нагрузки на уровне всего кластера хостов ESXi в целом, то есть бралась в расчет загрузка аппаратных ресурсов каждого из серверов ESXi, на основании которой рассчитывались рекомендации по миграциям vMotion виртуальных машин:

При этом раньше DRS запускался каждые 5 минут. Теперь же этот механизм запускается каждую минуту, а для генерации рекомендаций используется механизм VM DRS Score (он же VM Hapiness). Это композитная метрика, которая формируется из 10-15 главных метрик машин. Основные метрики из этого числа - Host CPU Cache Cost, VM CPU Ready Time, VM Memory Swapped и Workload Burstiness. Расчеты по памяти теперь основываются на Granted Memory вместо стандартного отклонения по кластеру.

Мы уже рассказывали, что в настоящее время пользователи стараются не допускать переподписку по памяти для виртуальных машин на хостах (Memory Overcommit), поэтому вместо "Active Memory" DRS 2.0 использует параметр "Granted Memory".

VM Happiness - это основной KPI, которым руководствуется DRS 2.0 при проведении миграций (то есть главная цель всей цепочки миграций - это улучшить этот показатель). Также эту оценку можно увидеть и в интерфейсе:

Как видно из картинки, DRS Score квантуется на 5 уровней, к каждому из которых относится определенное количество ВМ в кластере. Соответственно, цель механизма балансировки нагрузки - это увеличить Cluster DRS Score как агрегированный показатель на уровне всего кластера VMware HA / DRS.

Кстати, на DRS Score влияют не только метрики, касающиеся производительности. Например, на него могут влиять и метрики по заполненности хранилищ, привязанных к хостам ESXi в кластере.

Надо понимать, что новый DRS позволяет не только выровнять нагрузку, но и защитить отдельные хосты ESXi от внезапных всплесков нагрузки, которые могут привести виртуальные машины к проседанию по производительности. Поэтому главная цель - это держать на высоком уровне Cluster DRS Score и не иметь виртуальных машин с низким VM Hapiness (0-20%):

Таким образом, фокус DRS смещается с уровня хостов ESXi на уровень рабочих нагрузок в виртуальных машинах, что гораздо ближе к требованиям реального мира с точки зрения уровня обслуживания пользователей.

Если вы нажмете на опцию View all VMs в представлении summary DRS view, то сможете получить детальную информацию о DRS Score каждой из виртуальных машин, а также другие важные метрики:

Ну и, конечно же, на улучшение общего DRS Score повлияет увеличения числа хостов ESXi в кластере и разгрузка его ресурсов.

Кстати, ниже приведен небольшой обзор работы в интерфейсе нового DRS:

Еще одной важной возможностью нового DRS является функция Assignable Hardware. Многие виртуальные машины требуют некоторые аппаратные возможности для поддержания определенного уровня производительности, например, устройств PCIe с поддержкой Dynamic DirectPath I/O или NVIDIA vGPU. В этом случае теперь DRS позволяет назначить профили с поддержкой данных функций для первоначального размещения виртуальных машин в кластере.

В видео ниже описано более подробно, как это работает:

Ну и надо отметить, что теперь появился механизм Scaleable Shares, который позволяет лучше выделять Shares в пуле ресурсов с точки зрения их балансировки. Если раньше высокий назначенный уровень Shares пула не гарантировал, что виртуальные машины этого пула получат больший объем ресурсов на практике, то теперь это может использоваться именно для честного распределения нагрузки между пулами.

Этот механизм будет очень важным для таких решений, как vSphere with Kubernetes и vSphere Pod Service, чтобы определенный ярус нагрузок мог получать необходимый уровень ресурсов. Более подробно об этом рассказано в видео ниже:

Некоторое время назад мы писали о виртуальном модуле vCenter Event Broker Appliance (VEBA), который позволяет пользователям создавать сценарии автоматизации на базе событий, генерируемых в VMware vCenter Service. Например, VEBA может выполнять такие рабочие процессы, как автоматическое привязывание нужного тэга ко вновь создаваемой виртуальной машине. Работает он по модели "If This Then That".

Недавно было объявлено о выходе обновленной версии VEBA 0.3. Давайте посмотрим, что там появилось нового:

• Компонент VMware Event Router, который разделяет потоки Providers (компоненты вроде vCenter Server) и поток Processors (например, OpenFaaS). Больше об этом написано вот тут.

• Нативная поддержка AWS EventBridge в качестве Stream Processor. Это позволит пользователям VMware Cloud on AWS получить интеграцию с сервисами AWS. Более подробно можно почитать в документации.
• Поддержка всех типов событий vCenter (Event, EventEx и ExtendedEvent). В предыдущей версии VEBA поддерживалось не все множество событий, теперь же их поддерживается более чем 1600 для vSphere 6.7 Update 3, а также более 1900 для AWS 1.9. Подробнее об этом написано тут, а том, как вывести список этих событий, написано здесь.
• Теперь не нужно трансформировать тип события (например, из DrsVmPoweredOnEvent в drs.vm.powered.on). Полный список событий можно посмотреть тут.
• В файле определений stack.yaml можно подписаться на события более чем одного vCenter Server для определенной функции, например, DrsVmPoweredOnEvent или VmPoweredOffEvent.
• Доступна структура нагрузки самого vCenter.
• В структуре нагрузки VEBA теперь доступна поддержка спецификации Cloud Events.
• Упрощена схема развертывания шаблона OVF, а также появился новый комбобокс выбора Network Prefix (CIDR).

• Новый компонент statistics endpoint, который показывает использование ресурсов самого виртуального модуля VEBA, а также некоторые статистики по вызовам событий vCenter. Получить доступ к этому интерфейсу можно по адресу https://[VEBA]/stats:

• Обновленные примеры функций:
  • Все существующие примеры функций  были обновлены, чтобы отразить поддержку VEBA v0.3.
  • Официальные Docker-образы VMware теперь построены для примеров функций и не ссылаются на отдельные аккаунты. Все образы поддерживаются со стороны сообщества разработчиков.
  • Новая функция "echo" для Python, которая позволяет посмотреть как рабочая нагрузка будет видна с сервера vCenter.
  • Новая функция оповещения по почте о датасторах vSphere, которую очень хотели пользователи VMware Cloud on AWS.

Скачать VMware vCenter Event Broker Appliance 0.3 можно по этой ссылке.

На днях компания VMware объявила о скором выпуске платформы виртуализации VMware vSphere 7.0, где будет много интересных новых возможностей. Одновременно с этим было объявлено и о будущем релизе новой версии VMware vSAN 7.0 - решения для организации отказоустойчивых хранилищ для виртуальных машин на базе локальных хранилищ хост-серверов VMware ESXi.

Давайте посмотрим, что интересного было анонсировано в новой версии решения VMware vSAN 7:

1. Интеграция с vSphere Lifecycle Manager (vLCM) для обновления кластеров

Ранее администраторы vSphere использовали Update Manager (VUM) для обновлений платформы и драйверов, а утилиты от производителей серверов для обновления их микрокода (firmware). Теперь эти процессы объединяются в единый механизм под управлением vSphere Lifecycle Manager:

vLCM можно использовать для применения установочных образов, отслеживания соответствия (compliance) и приведения кластера к нужному уровню обновлений. Это упрощает мониторинг инфраструктуры на предмет своевременных обновлений и соответствия компонентов руководству VMware Compatibility Guide (VCG) за счет централизованного подхода на уровне всего кластера.

2. Службы Native File Services for vSAN

С помощью служб Native File Services кластер vSAN теперь поддерживает управление внешними хранилищами NFS v3 и v4.1. Это позволяет использовать их совместно с другими возможностями, такими как службы iSCSI, шифрование, дедупликация и компрессия. Теперь через интерфейс vCenter можно управлять всем жизненным циклом хранилищ на базе разных технологий и превратить его в средство контроля над всей инфраструктурой хранения.

3. Развертывание приложений с использованием Enhanced Cloud Native Storage

Напомним, что функции Cloud Native Storage появились еще VMware vSAN 6.7 Update 3. Cloud Native Storage (CNS) - это функциональность VMware vSphere и платформы оркестрации Kubernetes (K8s), которая позволяет по запросу развертывать и обслуживать хранилища для виртуальных машин, содержащих внутри себя контейнеры. По-сути, это платформа для управления жизненным циклом хранения для контейнеризованных приложений.

Теперь эти функции получили еще большее развитие. Тома persistent volumes могут поддерживать шифрование и снапшоты. Также полностью поддерживается vSphere Add-on for Kubernetes (он же Project Pacific), который позволяет контейнеризованным приложениям быть развернутыми в кластерах хранилищ vSAN.

4. Прочие улучшения

Тут появилось довольно много нового:

• Integrated DRS awareness of Stretched Cluster configurations. Теперь DRS отслеживает, что виртуальная машина находится на одном сайте во время процесса полной синхронизации между площадками. По окончании процесса DRS перемещает машину на нужный сайт в соответствии с правилами.
• Immediate repair operation after a vSAN Witness Host is replaced. Теперь процедура замены компонента Witness, обеспечивающего защиту от разделения распределенного кластера на уровне площадок, значительно упростилась. В интерфейсе vCenter есть кнопка "Replace Witness", с помощью которой можно запустить процедуру восстановления конфигурации и замены данного компонента.
• Stretched Cluster I/O redirect based on an imbalance of capacity across sites. В растянутых кластерах vSAN можно настраивать защиту от сбоев на уровне отдельных ВМ за счет выделения избыточной емкости в кластере. В результате на разных площадках могут оказаться разные настройки, и появится дисбаланс по доступной емкости и нагрузке по вводу-выводу. vSAN 7 позволяет перенаправить поток ввода-вывода на менее загруженную площадку прозрачно для виртуальных машин.
• Accurate VM level space reporting across vCenter UI for vSAN powered VMs. Теперь в vSAN 7 есть возможности точной отчетности о состоянии хранилищ для виртуальных машин, точно так же, как и для остальных хранилищ в представлениях Cluster View и Host View.
• Improved Memory reporting for ongoing optimization. Теперь в интерфейсе и через API доступна новая метрика потребления памяти во времени. Она позволяет понять, как меняется потребление памяти при изменениях в кластере (добавление и удаление хостов, изменение конфигурации).
• Visibility of vSphere Replication objects in vSAN capacity views. vSAN 7 позволяет администраторам идентифицировать объекты vSphere Replication на уровне виртуальных машин и кластеров, что упрощает управление ресурсами для нужд репликации.
• Support for larger capacity devices. Теперь vSAN 7 поддерживает новые устройства хранения большой емкости и плотности носителей.
• Native support for planned and unplanned maintenance with NVMe hotplug. Для устройств NVMe теперь доступна функция горячего добавления и удаления, что позволяет сократить время и упростить процедуру обслуживания.
• Removal of Eager Zero Thick (EZT) requirement for shared disk in vSAN. Теперь общие диски в vSAN не требуется создавать в формате EZT, что ускоряет развертывание в кластере vSAN нагрузок, таких как, например, Oracle RAC.

Больше информации о новых возможностях можно почитать в даташите о vSAN 7. Ну а технические документы будут постепенно появляться на StorageHub. Как и VMware vSphere 7, планируется, что решение vSAN 7 выйдет в апреле этого года.

На днях, как вы знаете, было много интересных новостей. И вот еще одна - компания VMware анонсировала большое обновление своей флагманской платформы виртуализации VMware vSphere 7. Напомним, что прошлая мажорная версия этого решения VMware vSphere 6.7 вышла весной 2018 года.

Сразу скажем, что это лишь анонс, а не объявление о доступности новой версии продукта для скачивания - как правило, GA версия vSphere появляется в течение месяца после анонса. Поэтому будем пока ожидать VMware vSphere 7 в апреле, а сегодня расскажем о новых возможностях этой платформы.

1. Улучшения сервисов VMware vCenter

Здесь можно отметить упрощение топологии vCenter Server SSO:

• Возможность апгрейда vCenter Server для пользователей с внешним PSC на консолидированную топологию на базе одного сервера vCSA.
• Embedded PSC теперь единственно возможный вариант развертывания. Внешний PSC больше не поддерживается.

Профили vCenter Server Profiles:

• Эта новая возможность для серверов vCenter работает точно так же, как Host Profiles работает для хостов. Теперь вы можете сравнивать и экспортировать настройки серверов vCenter в формате JSON для целей резервного копирования или применения этих настроек к другому серверу vCenter через REST API.

Функции vCenter Multi-Homing:

• Теперь для управляющего трафика vCSA можно использовать до 4 адаптеров vNIC, среди которых один vNIC зарезервирован для механизма vCHA.

Улучшения Content Library

• Теперь появилось новое представление для управления шаблонами, в котором доступны функции Check-In и Check-Out для управления версиями шаблонов и возможностью откатиться к предыдущей версии.
• Сначала делается Check-Out для открытия возможности внесения изменений, потом можно сделать Check-In для сохранения изменений в библиотеке.

Новая функция vCenter Server Update Planner:

• Новая возможность доступна как часть vSphere Lifecycle Manager (vLCM) для серверов vCenter.
• С помощью планировщика обновлений можно получать оповещения об обновлениях vCenter, планировать апгрейды, накатывать их, а также проводить анализ "что если" перед проведением обновления.
• Возможность выполнения pre-upgrade проверок для выбранного сервера vCenter.

2 Улучшения механизма VMware DRS

• Теперь DRS запускается каждую минуту, а не каждые 5 минут, как раньше.
• Для генерации рекомендаций используется механизм VM DRS score (он же VM Hapiness).
• Теперь это Workload centric механизм - это означает, что теперь в первую очередь учитываются потребности самой виртуальной машины и приложения в ней, а только потом использование ресурсов хоста.
• Расчеты по памяти основываются на granted memory вместо стандартного отклонения по кластеру.
• Появился механизм Scaleable Shares, который позволяет лучше выделать Shares в пуле ресурсов с точки зрения их балансировки.

3. Улучшения vMotion

Тут появились такие улучшения:

• Улучшения миграций для Monster VM (с большими ресурсами и очень высокой нагрузкой), что позволяет увеличить шанс успешной миграции.
• Использование только одного vCPU при отслеживании изменившихся страниц (page tracer) вместо всех vCPU, что меньше влияет на производительность во время миграции.
• Уменьшение времени переключения контекста на другой сервер (теперь меньше одной секунды). Достигается за счет переключения в тот момент, когда compacted memory bitmap уже передана на целевой сервер, вместо ожидания передачи full bitmap.

4. Новые функции vSphere Lifecycle Manager (vLCM)

Здесь можно отметить 2 улучшения:

• Функция Cluster Image Management, которая включает обновления firmware, драйверов и образов ESXi разных версий.
• Первоначальная поддержка решений Dell OpenManage и HP OneView.

5. Возможности Application Acceleration (Tech Preview)

Эти функции пришли от приобретенной компании Bitfusion. Они позволяют оптимизировать использование GPU в пуле по сети, когда vGPU может быть частично расшарен между несколькими ВМ. Это может использоваться для рабочих нагрузок задач приложений AI/ML.

Все это позволяет организовать вычисления таким образом, что хосты ESXi с аппаратными модулями GPU выполняют виртуальные машины, а их ВМ-компаньоны на обычных серверах ESXi исполняют непосредственно приложения. При этом CUDA-инструкции от клиентских ВМ передаются серверным по сети. Подробнее можно почитать у нас тут.

6. Функции Assignable Hardware

Эта возможность позволяет использовать так называемый Dynamic DirectPath I/O для машин, которым требуется работа с устройствами PCIe passthrough и Nvidia GRID. Теперь с его помощью можно подобрать хосты с определенными требованиями к аппаратным компонентам, такими как vGPU и PCIe. Это позволяет, в свою очередь, использовать для таких ВМ технологии HA и DRS Initial Placement в кластере, где есть совместимые по оборудованию хосты ESXi.

7. Управление сертификатами

Здесь 2 основных новых возможности:

• Новый мастер импорта сертификатов.
• Certificate API для управления сертификатами с помощью сценариев.

8. Возможности Identity Federation

Функции ADFS теперь поддерживаются из коробки, также будет поддерживаться больше IDP, использующих механизмы OAUTH2 и OIDC.

9. Функции vSphere Trust Authority (vTA)

• vTA использует отдельный кластер хостов ESXi, чтобы создать отдельный аппаратный узел доверия.
• Этот кластер сможет зашифровывать вычислительный кластер и его ВМ вместе с vCenter и другими управляющими компонентами.
• Можно использовать механизм аттестации, когда требуются ключи шифрования.
• Теперь проще добиться соблюдения принципа наименьших привилегий, а также расширить пространство аудита.

10. Возможность vSGX / Secures Enclaves (Intel)

• Расширения Intel Software Guard Extensions (SGX) позволяют переместить чувствительную логику и хранилище приложения в защищенную область, к которой не имеют доступа гостевые ОС и гипервизор ESXi.
• Возможности SGX исключают использование vMotion, снапшотов, Fault Tolerance и других технологий. Поэтому SGX лучше использовать только тогда, когда по-другому нельзя.

11. Новое издание vSphere with Kubernetes (Project Pacific)

О Project Pacific мы подробно рассказывали вот тут. Он представляет собой набор средств для преобразования среды VMware vSphere в нативную платформу для кластеров Kubernetes. vCenter Server предоставляет возможности по управлению кластерами k8s (любые кластеры старше n-2 будут обновлены). Также в решение интегрирован Harbor, который может быть включен для каждого пространства имен.

Доступно это пока только для пользователей VMware Cloud Foundation (4.0), так как решение завязано на компонент VMware NSX-T.

12. Улучшения VMware Tools

Функции Guest Store теперь доступны в гостевой ОС (такие как обновление VMware Tools из гостевой ОС).

13. Обновленное железо (VM Hardware v17)

Тут основные улучшения таковы:

• Virtual Watchdog Timer - теперь нет зависимости от физического железа для рестарта ВМ в случае, если гостевая ОС не отвечает.
• Precision Time Protocol (PTP) - для приложений очень чувствительных ко времени (например, торговые платформы для трейдеров) можно использовать PTP вместо NTP и назначать его использование для виртуальных машин.

14. Улучшения vSphere Client

Здесь появились следующие улучшения:

• Начала сохраняться история поиска.
• В API Explorer теперь лучше видны все доступные API.
• Для Code Capture появилась возможность выбора языка сценариев - PowerCLI, Javascript, Python или Go.

Конечно же, это далеко не все новые возможности VMware vSphere 7, представленные на днях. В ближайшее время мы расскажем еще много нового о них, а кроме того, посмотрим также и на анонсированные решения семейства VMware Tanzu, VMware Cloud Foundation 4 и vRealize 8.1.

Больше двух лет назад мы писали о средстве DRS Dump Insight, появившемся на сайте проекта VMware Labs. Это портал самообслуживания, куда пользователи могут загружать файлы дампов DRS. После этого будет выведена информация об операциях по перемещению виртуальных машин, которые рекомендует выполнить механизм балансировки нагрузки DRS.

Также мы писали о специальном плагине на базе HTML5 к vSphere Client для данного сервиса. Он добавляет функции утилиты DRS Dump Insight в интерфейс vSphere Client, работающего с сервером vCenter Server Appliance (vCSA).

На днях вышло обновление DRS Dump Insight 1.1, в котором появились следующие новые возможности:

• Пользователи теперь могут загружать несколько дампов, указав папку, в которой все они лежат.
• На базе загруженных дампов создается таймлайн миграций vMotion, по которому можно перемещаться в целях анализа нескольких дампов.
• Пользователи могут экспортировать результат анализа нескольких дампов в виде одного PDF-документа.
• Добавлена поддержка дампов VMware vSphere 6.5 Update 2, vSphere 6.5 Update 3 и vSphere 6.7 Update 3.
• Множество исправлений ошибок и улучшений движка анализа.

Воспользоваться утилитой DRS Dump Insight 1.1 можно по этой ссылке.

На сайте проекта VMware Labs появилась обновленная версия мобильного клиента для управления виртуальной инфраструктурой - VMware vSphere Mobile Client 1.5. Напомним, что о версии 1.3 мобильного клиента мы писали вот тут.

Давайте посмотрим, что нового в vSphere Mobile Client версий 1.4 и 1.5 (кстати, в Changelog версия 1.5 была ошибочно обозначена также как 1.4):

• Теперь поддерживаются прямые соединения к хостам ESXi, а не только через vCenter.
• Хост ESXi можно перевести в режим обслуживания (maintenance mode).
• Новое представление Cluster View, где видны события кластера.
• Появился диалог подтверждения при быстрых операциях с виртуальными машинами.
• Карточка кластера теперь показывает имеющиеся проблемы, статус DRS и HA, а также число событий vMotion.
• Карточка хоста ESXi показывает имеющиеся проблемы, число виртуальных машин, текущий аптайм и статус соединения.
• Выход из деталей ВМ обратно не обновляет страницу.
• Множество исправлений ошибок.

Скачать обновленный vSphere Mobile Client 1.5 можно по этим ссылкам:

• Android (в комбобоксе загрузки просто выберите apk-файл).
• iOS - до того, как ставить это приложение на айфон, нужно скачать приложение для тестировщиков Test Flight.

Также не забудьте посмотреть инструкцию о развертывании Notification Service (он доступен как Docker-контейнер), чтобы включить Push-уведомления на своих устройствах.

Это гостевой пост сервис-провайдера ИТ-ГРАД, предоставляющего в аренду виртуальные машины из облака. Вы наверняка много раз видели эпические фотографии из ЦОД-ов, в которых за горизонт уходят стойки забитые серверами, установлены мощные генераторы и системы кондиционирования. Многие любят хвастаться такими кадрами, но меня всегда интересовало, а как операторы ЦОД-ов выбирают и настраивают своё оборудование?
Таги: IT-Grad, IaaS, Datacenter, Enterprise, Cloud

Анонсы VMworld 2019 - часть 8. Что будет нового в DRS 2.0?

На конференции VMworld 2019, которая недавно прошла в Сан-Франциско, было представлено так много новых анонсов продуктов и технологий, что мы не успеваем обо всех рассказывать. Одной из самых интересных новостей стала информация про новую версию распределенного планировщика ресурсов VMware Distributed Resource Scheduler (DRS) 2.0. Об этом было рассказано в рамках сессии "Extreme Performance Series: DRS 2.0 Performance Deep Dive (HBI2880BU)", а также про это вот тут написал Дункан Эппинг.

Надо сказать, что технология DRS, позволяющая разумно назначать хосты ESXi для виртуальных машин и балансировать нагрузку за счет миграций ВМ посредством vMotion между серверами, была представлена еще в 2006 году. Работает она без кардинальных изменений и по сей день (13 лет!), а значит это очень востребованная и надежная штука. Но все надо когда-то менять, поэтому скоро появится и DRS 2.0.

Если раньше основным ресурсом датацентров были серверы, а значит DRS фокусировался на балансировке ресурсов в рамках кластера серверов ESXi, то теперь парадигма изменилась: основной элемент датацентра - это теперь виртуальная машина с приложениями, которая может перемещаться между кластерами и физическими ЦОД.

Сейчас технология DRS 2.0 находится в статусе Technical Preview, что значит, что никто не гарантирует ее присутствие именно в таком виде в будущих продуктах VMware, кроме того нет и никаких обещаний по срокам.

В целом, изменилось 3 основных момента:

• Появилась новая модель затраты-преимущества (cost-benefit model)
• Добавлена поддержка новых ресурсов и устройств
• Все стало работать быстрее, а инфраструктура стала масштабируемее

Давайте посмотрим на самое интересное - cost-benefit model. Она вводит понятие "счастья виртуальной машины" (VM Happiness) - это композитная метрика, которая формируется из 10-15 главных метрик машин. Основные из этого числа - Host CPU Cache Cost, VM CPU Ready Time, VM Memory Swapped и Workload Burstiness.

VM Happiness будет основным KPI, которым будет руководствоваться DRS 2.0 при проведении миграций (то есть цель - улучшить этот показатель). Также эту оценку можно будет увидеть и в интерфейсе. Помимо этого, можно будет отслеживать этот агрегированный показатель и на уровне всего кластера VMware HA / DRS.

Второй важный момент - DRS 2.0 будет срабатывать каждую минуту, а не каждые 5 минут, как это происходит сейчас. Улучшение связано с тем, что раньше надо было снимать "снапшот кластера", чтобы вырабатывать рекомендации по перемещению виртуальных машин, а сейчас сделан простой и эффективный механизм - VM Happiness.

Отсюда вытекает еще одна полезная функциональность - возможность изменять интервал опроса счастливости виртуальных машин - для стабильных нагрузок это может быть, например, 40-60 минут, а для более непредсказуемых - 15-20 или даже 5.

Еще одна интересная фича - возможность проводить сетевую балансировку нагрузки при перемещении машин между хостами (Network Load Balancing). Да, это было доступно и раньше, что было вторичной метрикой при принятии решений о миграции посредством DRS (например, если с ресурсами CPU и памяти было все в порядке, то сетевая нагрузка не учитывалась). Теперь же это полноценный фактор при принятии самостоятельного решения для балансировки.

Вот пример выравнивания такого рода сетевой нагрузки на виртуальные машины на разных хостах:

Модель cost-benefit также включает в себя возможности Network Load Balancing и устройства PMEM. Также DRS 2.0 будет учитывать и особенности аппаратного обеспечения, например, устройства vGPU. Кстати, надо сказать, что DRS 2 будет также принимать во внимание и характер нагрузки внутри ВМ (стабильна/нестабильна), чтобы предотвратить "пинг-понг" виртуальных машин между хостами ESXi. Кстати, для обработки таких ситуаций будет использоваться подход "1 пара хостов source-destination = 1 рекомендация по миграции".

Также мы уже рассказывали, что в настоящее время пользователи стараются не допускать переподписку по памяти для виртуальных машин на хостах (memory overcommit), поэтому вместо "active memory" DRS 2.0 будет использовать параметр "granted memory".

Ну и был пересмотрен механизм пороговых значений при миграции. Теперь есть следующие уровни работы DRS для различных типов нагрузок:

• Level 1 – балансировка не работает, происходит только выравнивание нагрузки в моменты, когда произошло нарушение правил DRS.
• Level 2 – работает для очень стабильных нагрузок.
• Level 3 – работает для стабильных нагрузок, но сфокусирован на метрике VM happiness (включено по умолчанию).
• Level 4 – нагрузки со всплесками (Bursty workloads).
• Level 5 – динамические (Dynamic) нагрузки с постоянными изменениями.

В среднем же, DRS 2.0 обгоняет свою первую версию на 5-10% по быстродействию, что весьма существенно при больших объемах миграций. При этом VMware понимает, что новый механизм DRS второй версии может родить новые проблемы, поэтому в любой момент можно будет вернуться к старому алгоритму балансировки с помощью расширенного параметра кластера FastLoadBalance=0.

По срокам доступности технологии DRS 2.0 информации пока нет, но, оказывается, что эта технология уже почти год работает в облаке VMware Cloud on AWS - и пока не вызывала нареканий у пользователей. Будем следить за развитием событий.